Media services providing rich media bandwidth consuming services, such as video unicast streams and TV (television) multicast streams, are heavily dependent on the bandwidth capability of the network infrastructure in order to deliver services of the best quality.
A video stream can be delivered in several qualities from basic 500 Kbytes up to a DVD (digital versatile disc) or HDTV (high definition television) quality (>20 Mbps) provided the required bandwidth is available. Often, networks are implemented on the OSI (open systems interconnection) layer 3 to ensure that a minimum bandwidth capability is available at the edge of the network to ensure that a subscriber is not consuming more bandwidth than that to which the subscriber has subscribed. However, no solutions exist that address the problem when the subscriber has exhausted the current available bandwidth.
In a scenario where a subscriber requests more than one video stream and the available bandwidth can only deliver one video stream, a centralised video service can ensure the user does not receive more bandwidth than that to which they have subscribed.
But, in a scenario where the subscriber performs its own subscription management, there is a possibility to offer a service in which the subscriber has available two video streams but within the requestor's current bandwidth subscription. Meaning, the subscriber would not be required to increase its bandwidth subscription in order to receive the two available video streams, but the subscriber would, in fact, receive the two video streams at a lower resolution, i.e., a resolution that ‘fits’ the subscriber's current bandwidth subscription.
Unfortunately, the above situation is complicated further if the same subscriber, in parallel to the video service, also utilises some peer-to-peer traffic from its PC (personal computer) that ‘fills up’ the current available bandwidth. Thus, the video server ‘thinks’ it knows the bandwidth capability of the subscriber's ‘bandwidth pipe’based on the subscriber's current bandwidth subscription and selects a ‘too good’ resolution without taking into account the fact that the PC has, for example, already consumed 25% of the available bandwidth.
One prior art solution is offered by EP 1523154 in which a method and system for offering push services to a mobile user using a push proxy which monitors the state of the mobile user equipment. The system comprises an application server which adapts the representation of the content data or the form in which the content data is communicated to the mobile user. A disadvantage of this system is that it is dependent on a specific application code set operating on the requestor's client device and thus requires dependency of a client application and general availability and support from manufactures.
Another solution can be found with reference to U.S. Pat. No. 6,848,004. Again, although the system adapts the content of the data to be transmitted to the requestor in dependence on the requestor's available bandwidth, the system relies on an application, i.e., Hot Media, on the client device and a specific data content data type. Thus, this solution is not suitable for an open standard network, and because a special application is required on the client in order to obtain data pertaining to network traffic, a certain amount of communication has to take place between the controller and the client. This communication uses bandwidth resources.
A further solution is described with reference to US 2005/0021726. A set of transcoding methods and complex algorithms are deployed to determine the bit rate over a particular network bandwidth pipe.
Thus, a lot of prior art exists that addresses the problem of adapting data content to an available bandwidth pipe. But all known prior art solutions either depend on specific networks, i.e., GPRS (general packet radio service), GSM (global system for mobile communications), etc., which have a more limited and expected bandwidth and/or specific code implemented and/or a specific file format architecture.